As the Internet began to evolve, personal computers (PCs) and desktop terminals were typical terminal devices used to access the Internet. Because the configurations of PCs and desktop terminals were relatively mature, their capabilities and attributes did not vary widely from device to device. For example, these network terminal devices could be considered as having the same form factor without any loss of effectiveness of content delivery. Accordingly, content authors, or web developers, could generate content for the PCs and terminals without needing to consider different form factors. The most common display device, a PC monitor, already had an essentially standard form-factor in place before the advent of the Internet.
Thus, although the sizes and shapes of PC monitors did vary from device to device, it was not necessary for the content author to customize the content to the physical aspects of the display. When it became necessary or desirable to modify the content to accommodate a particular PC display, the modification was usually simple enough so as not to require the intervention of the content author. Such simple modifications were typically incorporated by a browser lay-out manager, or by some automatic mechanism on the user network terminal device itself.
On the Internet, content is usually requested by user for display on or delivery to a terminal device. Until recently, the terminal device most commonly used would be either a desktop Personal Computer (PC) or a Network Terminal or Workstation. More recently, with the development of wireless internet and handheld display devices, the concept of ‘terminal device’ has been extended to a much wider array of delivery devices, including for example, cellular telephones (having communication and display methods such as WAP, Imode, and HDML), PDAs (such as Palm Pilot, Psion, and Revo) with wireless or wired access to the network, and combinations of PDAs and cellular telephones. In general, ‘terminal device’ will be understood to mean any device which has a capability for making a request for Internet content, and has a capability of delivering the Internet content to the terminal device user. It should be pointed out that a terminal device may not necessarily include a display, as in the devices intended for use in an automobile, or for use by vision-impaired persons.
In the present state of the art, the Internet can also be accessed by other types of user network terminal devices, such as wireless data transceivers or mobile stations. While this has created new and expanding information service possibilities for the users, the content author has been presented with the challenge of providing content for new network terminal devices having diverse form factors.
With the increased use of cell phones, Personal Data Assistants (PDAs), and other types of wireless terminal devices, the content author can no longer consider the network terminal device displays to be essentially equivalent to one another. The capabilities, features, and variations in form factor among such devices are not insignificant, and ignoring these differences usually results in a decrease in the fidelity of content delivery. Moreover, the development of newer wireless terminal devices continues, with the availability of new features and applications as well as additional changes in the basic form factor.
Software developers and content authors incorporate new features or a change to an existing feature so as to fully realize the capabilities of more sophisticated user network terminal devices without overwhelming simpler terminal devices. However, as the number of different types of network terminal devices continues to grow, it becomes increasingly difficult for a content author to generate code to automatically convert the content to fit the user network terminal device, for example, as both created content and terminal devices become more numerous.
There are at least three options available to address this situation. In the first option, the content author creates content for the simplest type of network terminal device and provides this basic content to all types of terminal devices, from simplest to the most sophisticated (i.e., content is created for the lowest common denominator). The first option requires minimal input from the content author, but it precludes utilizing the capabilities available in the more sophisticated devices.
In the second option, the content author can precisely identify the capabilities of all types of network terminal devices and then generate respective content versions for each type. The second option provides the most effective utilization of the capabilities of the various user network terminal devices but requires a greater effort on part of the content author.
The second option is not practical for several reasons. For example, there are no standard methods for identifying or describing the capabilities of network terminal devices. Accordingly, a design solution developed without reference to a standard method will therefore be a custom or an individual solution which cannot be readily shared by other content developers, or even reused by the original content developer. As another example, maintaining a list of user network terminal device characteristics becomes impractical as new designs and features appear as a continuation of the ongoing development of terminal devices. Moreover, the task of generating content to precisely match the capabilities of particular user network terminal devices, known in the relevant art as ‘fine-grain matching,’ becomes very daunting.
In most instances, an automated process, devoid of any knowledge of the meaning of the content, is inadequate for adapting authored content to a particular user network terminal device. For example, if an authored page contains a picture, but is loaded into an ‘audio-only’ device, the picture cannot be ‘read’ and will usually be ignored. In some conventional systems, replacement ‘text’ may be substituted in place of the picture.
However, if the content author knew that the content might be directed to audio-only devices, he might have included in the authored content an audio file that assisted in visualizing the picture. Other examples could be provided of circumstances in which the author may have had a ‘better’ idea of how to modify his content, where the particular modification depends on the device type. Autonomous systems, on the other hand, will ignore such intent resulting in a system having a lower fidelity. As used in the present specification, the term ‘author intent’ will refer to the inclusion of the intent of the content author as a meta-data (viz., not as part of the main data but as auxiliary information).
In the third option, there is provided an autonomous system having adequate intelligence to make correct decisions in transforming the content for a particular user network terminal device. The autonomous system, when invoked, would transform ‘device-independent’ content into ‘device-specific’ content. In way of example, the automatic system may utilize the process of ‘web-clipping,’ where applicable software makes use of an intelligent scheme in determining how to modify content formatted for a conventional terminal device (e.g., a personal computer) into a format suitable for a wireless terminal device (e.g., a Palm PDA).
In general, there are similar situations in which the intent of the author is required when modifying the content. It is usually not possible for a system to automatically make appropriate decisions without first having knowledge of the author intent. A practical system would thus require automation as well as author's knowledge of the different devices in which the content may be displayed. The capabilities of such a system can range from a substantially automatic system to a system primarily controlled by the author or developer.
The content typically contains no author information to assist in such a modification process. Furthermore, in situations where it becomes necessary to generate supplemental content, that is, to ‘fill’ a larger network terminal device display with content not initially provided, the ‘fill process’ requires the authored content to include all the information necessary to enable an otherwise automatic system to carry out the content specialization in an effective manner. In other words, a system which takes ‘hints’ from the author is more practical than a fully-automatic system which utilizes no such inputs.
In the present state of the art, the content developer does not have standardized tools by which to conduct independent authoring. The content developer may make use of technologies such as Resource Description Format (RDF), to describe user preferences and wireless terminal device capabilities. RDF, an XML syntax for describing resources, is not used alone but can be used in conjunction with a Composite Capability/Preference Profile (CC/PP) or with a User Agent Profile (UAProf) to describe the features of a wireless terminal device, for example.
CC/PP uses RDF to describe device capabilities by setting up a detailed framework for such purposes. However, describing the device is accomplished in a ‘developer-unfriendly’ manner. For example, CC/PP documentation provides the following ‘print and display’ vocabularies:                charWidth:        charHeight:        charset:        pix-x:        pix-y:        color: (e.g., ‘binary,’ ‘grey,’ ‘limited,’ ‘mapped,’ ‘full’)        
While, in theory, this information is enough to allow a content author to ‘tailor’ content for the network terminal device, the process is not straightforward. Absolute pixel values and character sizes are too fine-grained in comparison to the process by which content is differentiated between network terminal devices. For example, such fine-grained information may be useful in the task of calculating line breaks or page widths, but is not suitable for expressing author intent.
UAProf, developed by the WAP Forum, is similar to CC/PP by using RDF to describe the network terminal device. However, use of UAProf poses problems similar to CC/PP, as discussed above, in that the defined variables, listed below, are not appropriate for developer usage.                Model        BitsPerPixel        OutputCharSet        PointingResolution        PixelAspectRatio        NumberOfSoftKeys        ScreenSize (e.g., 160×160, 640×480)        ScreenSizeChar (e.g., 12×4, 16×8)Such information is not useful precisely because it is presented in too great a detail.        
As an alternative, Extensible Hypertext Markup Language (XHTML) @media tags allow specific stylesheets to be loaded depending on the type of media (e.g., desktop, handheld, phone, printer). The job of writing the appropriate stylesheets is still left to the developer, and this is not a trivial task by any means. Moreover, XHTML @media tags is designed more for formatting than for content differentiation based on author intent and is not typically considered for displaying author intent.
It can be appreciated by one skilled in the relevant art that, although it is possible for a developer to adapt his content to the network terminal device using either CC/PP or UAProf attributes, this method still presents a challenge to the content author. Moreover, by distinguishing between network terminal devices on the basis of features such as character size or number of soft keys, the adaptation process may become more detailed and complex than is desirable. Thus, the task has been made more difficult by requiring the content author to address features in general instead of being selective in first establishing which features are really necessary to properly display content. In short, the description of a device feature in either UAProf or CC/PP is not ‘developer-friendly.’
As should be understood, these conventional methods using CC/PP and UAProf have not attained acceptance in the relevant art because of the mismatch between minimizing author effort and maximizing utilization of devices for that level of effort. It can be shown that the conventional methods are, essentially, an all-or-nothing solution, and using a conventional method requires the content author to determine how different content-types should be annotated for a given feature.
What is needed is a system and method that predictably reflect the intent of the content author when content is displayed in a network communication terminal device, even if the content requires transformation for compatibility with the network communication terminal device.